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The Figaro data reduction system originated at Caltech around 1983. It was based on concepts 
being developed in the U.K. by the Starlink organisation, particularly the use of hierarchical 
self-defining data structures and the abstraction of most user-interaction into a set of ‘parameter 
system’ routines. Since 1984 it has continued to be developed at AAO, in collaboration with 
Starlink and Caltech. It has been adopted as Starlink’s main spectroscopic data reduction 
package, although it is by no means limited to spectra; it has operations for images and data 
cubes and even a few (very specialised) for four-dimensional data hypercubes. It has continued 
to be used at Caltech and will be used at the Keck. It is also in use at a variety of other 
organisations around the world. 

Figaro was originally a system for VMS Vaxes. Recently it has been ported (at Caltech) to run 
on SUNs, and work is underway at the University of New South Wales on a DecStation 
version. It is hoped to coordinate all this work into a unified release, but coordination of the 
development of a system by organisations covering three continents poses a number of 
interesting administrative problems. 

The hierarchical data structures used by Figaro allow it to handle a variety of types of data, and 
to add new items to data structures. Error and data quality information has been added to the 
basic file format used, error information being particularly useful for Infra-red data. 
Cooperating sets of programs can add specific sub-structures to data files to carry information 
that they understand (polarimetry data containing multiple data arrays, for example), without 
this affecting the way other programs handle the files. Complex instrument-specific ancillary 
information can be added to data files written at a telescope and can be used by programs that 
understand the instrumental details in order to produce properly calibrated data files. Once this 
preliminary data processing has been done the resulting files contain ‘ordinary’ spectra or 
images that can be processed by programs that are not instrument-specific. The structures 
holding the instrumental information can then be discarded from the files. 

Much effort has gone into trying to make it easy to write Figaro programs; data access 
subroutines are now available to handle access to all the conventional items found in Figaro 
files (main data arrays, error information, quality information etc), and programs that only need 
to access such items can be very simple indeed. A large number of Figaro users do indeed 
write their own Figaro applications using these routines. 

The fact that Figaro programs are written as callable subroutines getting information from the 
user through a small set of parameter routines means that they can be invoked in numerous 
ways; they are normally linked and run as individual programs (called by a small main routine 
that is generated automatically), but are also available linked to run under the ADAM data 
acquisition system and there is an interface that lets them be called as part of a user-written 
Fortran program. 

The long-term future of Figaro probably depends to a large extent on how successfully it 
manages the transition from being a VMS-only system to being a multi-platform system. 
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